Bug

In the Copy parameter-fill flyout, a Text parameter's box cleared itself on every keystroke and the Copy button never enabled. Symptoms: the caret shows (focus is fine), typing clears the box, a single Ctrl+V clears it, a double Ctrl+V leaves text visible — but the Preview still shows the raw {token} and Copy stays disabled.

Cause

Each row in the flyout rendered both a TextBox and a ComboBox, toggled with Visibility. But Visibility="Collapsed" does not deactivate a binding — so for a Text parameter the hidden ComboBox stayed SelectedItem="{x:Bind Value, Mode=TwoWay}" bound to the same Value as the TextBox:

1. Type a char → Value is set → PropertyChanged fires.
2. The hidden ComboBox receives the new Value, can't find it in its (empty) Options, and coerces SelectedItem to null — writing null back into Value.
3. The TextBox clears; Value stays null → token unresolved → Preview keeps {token} and Copy never enables.

The snip editor was unaffected because its Type dropdown binds a different property (TypeIndex). This was long-standing — Text params in the flyout never accepted typing; it only surfaced now that imported snips are the first that need a typed value rather than a default or a choice.

Fix

A parameter row is either Text or Choice, fixed for its lifetime. Realise only the relevant control via x:Load, so the unused control is never created and its binding never fires. Typed values now stick, the preview resolves live, and Copy enables.

Testing

• Core: 214 tests pass, including a new regression test that fills a path-like value (quotes, backslashes, spaces, hyphen) and asserts the command resolves and IsCopyEnabled becomes true. (The bug itself was in XAML binding; this guards the view-model/engine side.)
• WinUI App head compile-verified on Windows: 0 warnings, 0 errors.
• ⚠️ Interaction (actually typing in the flyout) needs a manual check on Windows — please confirm typing a value into a Text parameter now sticks, updates the Preview, and enables Copy.

🤖 Generated with Claude Code